Dark mode support for HTML output - #11831
Conversation
| : sets the CSS `font-family` property on `code` and `pre` elements. | ||
|
|
||
| `monobackgroundcolor` | ||
| : sets the CSS `background-color` property on `code` elements | ||
| `monobackgroundcolor`, `monobackgroundcolordark` | ||
| : sets the CSS `background-color` property on `code` and `pre` elements |
There was a problem hiding this comment.
Note: affecting pre also is not a new change, just documenting existing behavior.
jgm
left a comment
jgm
left a comment
There was a problem hiding this comment.
I made some suggestions on simplifying the CSS template. (Not exhaustive but you should get the idea.) As noted, leave the man pages unchanged for now. As for browser support, if the CSS can be simpler I'd accept 98% support for post-2010 browsers, I think.
|
Okay, removed the man page changes and updated the template per your suggestions. In some cases this is definitely clearer, in others it looks a bit messier to me, but it at least matches your suggestions. The only weird case is with the |
a853f2d to
66f5ac1
Compare
| color: light-dark($if(fontcolor)$$fontcolor$$else$#1a1a1a$endif$, $if(fontcolordark)$$fontcolordark$$else$#fdfdfd$endif$); | ||
| background-color: $if(backgroundcolor)$$backgroundcolor$$else$#1a1a1a$endif$; | ||
| background-color: light-dark($if(backgroundcolor)$$backgroundcolor$$else$#1a1a1a$endif$, $if(backgroundcolordark)$$backgroundcolordark$$else$#fdfdfd$endif$); | ||
| color-scheme:$if(fontcolor)$ light$elseif(backgroundcolor)$ light$elseif(fontcolordark)$$elseif(backgroundcolordark)$$else$ light$endif$$if(fontcolordark)$ dark$elseif(backgroundcolordark)$ dark$elseif(fontcolor)$$elseif(backgroundcolor)$$else$ dark$endif$; |
There was a problem hiding this comment.
The way the logic works out, this should always output at least one of the two.
| $if(linkcolor)$ | ||
| color: light-dark($linkcolor$, $if(linkcolordark)$$linkcolordark$$else$inherit$endif$); | ||
| $elseif(linkcolordark)$ | ||
| color: light-dark(inherit, $linkcolordark$); | ||
| $endif$ |
There was a problem hiding this comment.
These avoid outputting a redundant light-dark(inherit, inherit).
|
|
||
| * If the browser does not support `light-dark` (older than ~2024), then it will | ||
| always choose light mode, regardless of this override. | ||
| * When printing, light mode is always chosen. |
There was a problem hiding this comment.
Maybe this is misleading. We have in print css:
html {
background-color: $if(backgroundcolor)$$backgroundcolor$$else$white$endif$;
}
body {
background-color: transparent;
color: black;
}
which means that black on transparent is always used regardless of color. So, it's not that light mode is chosen; rather, black-on-transparent is chosen.
I'm actually not sure why background-color is still defined in HTML, since it's overridden in body: is there a point to this?
There was a problem hiding this comment.
Yeah, I definitely think that we shouldn't be overriding background-color for print mode at all, but technically, it was, so, I kept it. In this case, html's background color still shows through because of the choice of transparent for body.
There was a problem hiding this comment.
The rationale for setting the print background-color to transparent was that, in the normal case where you print a web page, you generally just want a white paper background; you don't want the printer to make the whole background slightly darker just because the screen is that way. But if the html background color is showing through, then it's not working as intended. Why do we set background color on html at all? Shouldn't all visible elements be in body?
There was a problem hiding this comment.
Decided to take a stronger approach: the @media print CSS now explicitly overrides all colors to black and sets all background colors to transparent where they might be overridden. It also resets padding on code and pre since those are dependent on color variables.
It currently ignores syntax highlighting, which as discussed is probably a separate issue.
|
thanks! |
2 participants
Originally jgm/djot#409, before I found out this was part of pandoc.
Essentially, the goal here is to add a "just works" dark mode support to pandoc's HTML generation while being minimally intrusive and not breaking custom schemes. It consists of the following changes to the styles.html template:
quotecolorandquotebordercolorare added as these are the only two unique colors in the stylesheet that weren't already configurable. They affect the styling ofblockquotetags.*colorvariables for the HTML generation now has a*colordarkfriend, which controls the color in dark mode.monobackgroundcolorifmonobackgroundcolorormonobackgroundcolordarkis provided, although the provided color will only work in the respective mode. (it usesinheritotherwise)color-schemeis emitted to either allow both dark and light mode by default, or restrict to only light or dark mode depending on what variables the user defines. (see below)Part of being minimally intrusive is only enabling light and dark mode in the following cases:
However, because pandoc's template conditions can only check one variable at a time, only the
fontcolorandbackgroundcolor(and their*darkversions) variables is checked to determine whether the user has overrided the colors, and thus, which schemes they would like to be enabled. This means that, in general, if a user has changedbackgroundcolororfontcoloronly, that means they will default to only light mode, and if a user has changedbackgroundcolordarkorfontcolordarkonly, it will default to only dark mode.There are a few other caveats, but these have been added to
MANUAL.txtand hopefully are clear.Since the
light-darkcoloring is a "new" standard (around 2024, 88% coverage), it includes explicit fallbacks for light mode. However, as part of implementing this change,currentColorwas added to a few color definitions as opposed to repeating the font color, since this has been supported since 2010 at 98% availability.That said, I have no idea what pandoc wishes to support browser-wise, and am only taking a conservative approach out of caution. I don't mind removing the fallbacks if you'd prefer.